JAX enter: How do you feel about the new six-month cycle and the new rhythm? After all, Java 10 was the fastest release in Java’s 23-year history and now we’re already 2 months away from Java 11.

I think my opinion compared to the last Java interview series hasn’t changed much. We’ve seen a lot of traction for all the material that was published around modularity and developers are trying to learn as much as possible about all the new features that are available now. With just roughly 150 days until Java 8 gets end-of-lived, I believe that this isn’t enough time for most companies to switch over their production systems. That nicely fits into the new licensing model from Oracle and gives enterprises a lot more room to migrate. With a lot of articles and experiences being published about the necessary steps to get your project onto Java 11 it shouldn’t be a big headache for smaller ones. The bigger ones will however require a lot more than just the three step process to compile, run, modularize.
I was thinking if the fast release cadence allows for enough feedback from experiences. And I believe that we will find out after the first LTS version comes out and how stable it really is.

JAX enter: Do you think the new release cadence will lead to fatigue or is it just keeping developers on their toes?

Hard to say right now. It for sure requires a lot more learning for everybody involved. Somedays it might even feel that there isn’t a lot of difference anymore to other fast moving languages that are living on the bleeding edge. I am not sure if Java and the ecosystem aren’t losing one of their biggest advantages by speeding things up like this. Ultimately we will see the judgement by developers. If they still believe it is worth the effort to stay on top or if they will more easily also consider other languages when it comes to quick solutions. My perception is that the language, tools and framework “diversity” developers can choose from today has become insanely broad with Java being the proverbial island in the middle. I’ve always believed in the slightly altered version of an African saying that if you want to go fast you have to go alone. But if you want to go far you need to do that with a strong community of many voices giving you the chance to incorporate their experiences. This naturally slows things down. In a good way.

JAX enter: Describe your favorite Java 11 feature.

Two very different things. I can’t just select one. First and most important is the inclusion of the Flight Recorder (JEP 328) together with the now open sourced Mission Control this will bring a lot of power to developers that need performance and trouble shooting help. JEP 318: Epsilon garbage collector. This will be very effective when it comes to distributed systems that consist of a lot of super short lived services.

JAX enter: Java 11 will be “lighter” in the sense that JavaFX will soon be decoupled from the JDK, we’re saying goodbye to Java EE modules and Nashorn JavaScript engine will be deprecated. What’s left to axe?

I’d call it natural progression. We all badly want the core runtime to be small enough to be run on a variety of devices and also have a tremendously fast startup. Distribution sizes have to go down too to make it easier to embed the JDK. If the OpenJDK focuses on hooks and groundwork (e.g. Flight Recorder APIs + external Mission Control tooling) the ecosystem can more easily evolve and extend beyond what’s possible within the OpenJDK itself.

JAX enter: A lot of developers are still using Java 8. What does this mean for Java 11 adoption? Do you think Java 11 will be important or big enough to make them want to drop Java 8?

This particular situation isn’t exactly about “importance” for developers. I think that feasibility is the bigger challenge. Companies have postponed migration from 8 to 9 because of the complexity of the module system. This also has been a dot-zero release which barely makes it into production. If they have switched, it was used without modularity at all. Same situation was true for 10. With 11 enforcing modularity this will be the first real migration milestone for many projects. We now have a reasonable number of experiences about how to use the module system and how to migrate and build new software on top. My guess is that Java 8 to 10 will be treated as legacy until these projects are needed and new projects are set up with Java 11 from the beginning.

JAX enter: Speaking of Java 8, public updates will remain available for individual, personal use through at least the end of 2020 but business users won’t be that lucky — the ‘public updates’ tap will be turned off in January 2019. A lot of Java developers believe that this decision is “ruining Java”. What’s your take on that?

It won’t be a big issue for companies that are Oracle customers already. I can imagine corporate licenses and bundles. The problem will be solved for them. Other alternatives from Red Hat or IBM are just around the corner. There will be some way to get support for Java legacy. It is a change in process but I don’t see this as something that ruins Java.

JAX enter: Nashorn JavaScript engine will soon be deprecated and the most viable alternative seems to be GraalVM. What does GraalVM have that Nashorn doesn’t? Should Nashorn be kept alive by the community?

It is hard to compare Nashorn with the GraalVM. First of all there are many projects under that acronym. It’s a new JIT compiler for HotSpot, and also a new polyglot virtual machine. I personally see it as an opportunity to rethink the compiler design for Java and other languages. Re-creating a better Java compiler in Java has a lot of advantages in general. Nashorn on the other side was designed to be a JavaScript engine on the JVM. I haven’t seen a lot of production systems build on it and to me it always has been a very distinct and complete test for the new invokedynamic call-site that was introduced with Java 8. My expectation is that GraalVM will deliver better results when running JavaScript code than anything that has been sitting on top of HotSpot. For sure there is an opportunity for the community to take it over but I am not sure that it’s worth it.

JAX enter: How do you feel about ZGC? Can it make latency a non-issue for Java applications?

An interesting approach. Azul has had large heap garbage collection for a very long time already. Red Hat has Shenandoah. With ZGC coming to the OpenJDK it will deliver an alternative for szenarios that need this and can’t work within normal heap sizes. What I feel though is that there are very few nieche use-cases that are profiting from this. Especially with Microservices architectures where everything is about super quick startup times and small footprints. The low latency parts will for sure meet these requirements.
There are some first numbers out in the wild in a Fosdem presentation (http://cr.openjdk.java.net/~pliden/slides/ZGC-FOSDEM-2018.pdf) which look promissing.

JAX enter: Demand is growing for serverless platforms. Will serverless begin a major reshaping of Java?

Generally speaking this is another polyglot world that is less about the programing language used but more about the developer productivity that is available. Oracle is pushing the Fn project (http://fnproject.io/) here but there are plenty of other alternatives to explore. The more general direction of the industry is to cut smaller services which can be run independently. That implies that Java will need better startup qualities and could use improvements in it’s JIT mechanisms. The newly introduced projects like Graal and ZGC are starting to address this field from an infrastructure perspective. We’ll see how much more can and will have to be done and how Java as a programming language find the balance between the maturity and stability it provides so far and the innovative innovation cycles we are facing right now.

JAX enter: What features would you like to see in Java 12?

I’m still eagerly monitoring the progress of project Valhalla which would be a great addition. Of course Graal as a the new standard JIT compiler would be amazing.